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REMARKS 

A. Amendments 

Applicants have voluntarily amended Claims 1, 6-8, 64, and 67. These amendments 
were made solely to clarify the respective claims, and are not intended to respond to any of the 
Examiner's rejections, including rejections based on the below-cited references. Applicants 
believe that the Examiner's rejections (of the previously presented claims) were in error, and 
submit the arguments below in support. Thus, Applicants request withdrawal of the outstanding 
rejections on the basis of the below arguments, not on the basis of the above amendments, with 
the exception of the rejection of Claim 67 under Section 112, first paragraph, as described in 
greater detail below. 

Applicants have added new Claims 71-75 and respectfully request allowance. With 
respect to Claim 75, it should be allowable for at least the reasons listed below with respect to 
Claim 62. 

B. Discussion of Rejection of Claims 62 and 67 for Nonstatutory Double Patenting 

The Examiner rejected Claims 62 and 67 on the ground of nonstatutory obviousness-type 
double patenting as being unpatentable over claims 1 and 5 of U.S. Patent No. 7,146,524. 
Applicants ask the Examiner to reconsider this rejection. For example, the Examiner states "it is 
obvious ... to modify the broader claims (i.e., 62 and 67) of [the] instant invention with common 
details as recited in the claim 1 and 5 of the 7,146,524 patent for the purpose to clarify the 
limitations of his/hers invention." This is an improper application of obviousness-type double 
patenting as the claims in the two cases are directed to different subject matter. The Examiner 
has failed to make even a prima facie case of obviousness-type double patenting. In particular, 
MPEP section 804 requires that the Examiner set forth the differences between the claims and 
then provide the reasons why the invention defined in the claim at issue would have been an 
obvious variation of the invention defined in a claim in the patent. In this case, however, the 
Examiner has not even specified what the Examiner believes are the "common details" or 
explained why it would allegedly be obvious to modify claims 62 and 67 of the present 
application. Furthermore, the Examiner has failed to explain why the issuance of a second patent 
would provide unjustified extension of the right to exclude granted by a patent. Obviousness 
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type double patenting is simply not applicable in this case, and for these reasons the Examiner is 
respectfully requested to withdraw this rejection. 

C, Discussion of Rejection of Claims 62-70 Under 35 U.S.C. 112 

The Examiner rejected Claims 62-70 under Section 112, first paragraph, as failing to 
comply with the written description requirement, alleging that the claim element "assemble the 
file" is not supported in the application. Applicants respectfully disagree that "assemble the file" 
is not supported in the application. Applicants have amended Claim 67 to substitute the word 
"collect" for the word "assemble." Support for the claim element "collect the file" may be found, 
at least, in the following passage and surrounding text of the specification: "Further, each smart 
storage unit may respond to a file request by locating and collecting the file's data from the set of 
smart storage units." US 20Q3/QQ33308 Ah page 2, para. 0034. Applicants respectfully submit 
that Claim 67 does not fail to comply with the written description requirement. 

As discussed above, Applicants have not amended the claims in direct response to the 
Examiner's rejections with the exception of the amendment described immediately above with 
respect to Claim 67 ("collect" in place of "assemble"). Although Applicants believe that the 
element "assemble the file" is supported in the specification, Applicants rely on the above- 
described amendment, and not on argument, to respond to the Examiner's rejection. 

Applicants note that Claim 62 does not include the claim element "assemble the file." 
Claim 62 cannot, therefore, fail to comply with the written description requirement on this 
ground of rejection. Finally, Applicants observe that Claims 63-66 and 68-70 depend from 
Claims 62 and 67, respectively, and do not, therefore, fail to comply with the written description 
requirement for the same reason that Claims 62 and 67 do not. 
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D. Discussion of Rejection of Claims 1-12 and 43 under 35 U.S.C. 112 

The Examiner rejected Claims 1-12 and 43 under Section 112, second paragraph, as 
being indefinite, alleging that the claim element "distributing ... in a manner for the storage 
system and for each file" is not defined in the specification. Applicants respectfully submit that 
the above-mentioned claims are not indefinite based, at least, on the following passages of the 
specification (US 2003/0033308 Al): page 2, paras. 0036-37; page 3, para. 0048; and pages 6-7, 
paras. 0085-93. Applicants respectfully submit that Claims 1-12 and 43 are not indefinite. 

E. Discussion of Rejection of Claims 1-12, 43 and 62-70 Under Section 103(a) 

The Examiner rejected Claims 1-12, 43 and 62-70 under Section 103(a) as being 
unpatentable over Evans et al. (US Publication No. 2003/0014391), in view of Massa et al. (US 
Patent No. 6,934,878). Applicants respectfully disagree with the Examiner's rejection. 
Specifically, Applicants disagree with the Examiner's conclusion that Evans "discloses a 
distributed file system." Office Action mailed 02/15/2006, page 5. Evans neither discloses a 
distributed file storage system nor is combinable with Massa in a way that would disclose a 
distributed file storage system. 

Evans "relates to a method of operating a transmitter to distribute data elements to one or 
more receivers over a network." Evans , page 1, para. 0001. Evans identifies a problem of 
unnecessary transmissions in multicast data distribution applications: 

However, despite the advantageous savings in network use by multicast 
techniques, there remain data distribution applications in which data are 
transmitted unnecessarily. For example, a sports news service may categorise 
[sic] news service articles according to the type of sport, a different multicast 
address being allocated to each sport so that all news articles for a particular sport 
are sent to the same respective multicast address. In some sports, there may be a 
great many news articles available for transmission at certain times, for football 
for example. A client server electing, on behalf of its users, to receive news about 
football, would need to receive every available news article transmitted over the 
football multicast address just in case its users wish to read a particular one of 
them. (Evans, page 1, para. 0006). 

Evans attempts to reduce these unnecessary transmissions by allowing users to optionally receive 
only meta-information related to the actual data being distributed. Evans , page 1, paras. 0007- 
0014. This meta-information may include, for example, a "short summary or abstract of the 
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document or merely a title." Id., at 0014. Recipients may then optionally request the full data 
set. IcL 

Applicants respectfully suggest that the Examiner has misinterpreted Evans. Unlike the 
claimed invention, Evans is not an "intelligent distributed file system [that] enables the storing of 
file data among a plurality of smart storage units which are accessed as a single file system." US 
2003/0033308 Ah Abstract, lines 6-7. In the Office Action, the Examiner stated: "Evans and 
Massa are both in the same endeavor to optimize the storing of data over program storage device 
[e.g., Evans: claim 6, Massa: Fig. 1] . . . Office Action mailed 02/15/2007 , page 7. Evans, 
however, does not attempt to optimize data storage. 1 Instead, Evans attempts to optimize 
network traffic. Optimizing network traffic and optimizing data storage are entirely different 
problems, requiring solutions that comprise entirely different configurations of both hardware 
and software. Accordingly, the claim elements alleged to be disclosed are not found in Evans. 

With respect to Claim 1, the Examiner concludes that only the "allocator module" 
element is not disclosed by Evans. Applicants disagree. For purposes of brevity, we specifically 
analyze only some of the claim elements allegedly disclosed by Evans. With respect to Claim 1, 
applicants claim a distributed file storage system comprising, in part: (1) "a first file portion of 
the file comprising a first set of file data stored in the first storage module"; and (2) "a second file 
portion of the file comprising a second set of file data stored in the second storage module, 
wherein the second set of file data is different from the first set of file data." With reference to 
Evans, the Examiner alleges that: (1) "Fig. 2b and associated text" disclose "a first file portion of 
the file comprising a first set of file data stored in the first storage module"; and (2) "FIG. 2a and 
associated text" disclose "a second file portion of the file comprising a second set of file data 
stored in the second storage module, wherein the second set of file data is different from the first 
set of file data." It appears that the Examiner believes that the "set-to-IP address conversion 



1 The Examiner appears to believe that Evans is directed to data storage based on Claim 6 
of Evans. Claim 6 claims "[a] program storage device readable by a processing apparatus, said 
device embodying a program of instructions executable by the processing apparatus to perform 
method steps for transmitting a data element over a network . . . ." Claim 6 is written in the form 
of a Beauregard claim, and the "storage device" referred to is some form of computer readable 
medium, such as a magnetic disk in a hard drive, capable of storing instructions. The term 
"storage," however, is used only to describe the storage of the instructions for operating the 
invention of Evans, not the storage of a file system implemented by Evans. 
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table" illustrated in Fig. 2b is a "first file portion/' and that the "site area multicast directory" 
illustrated in Fig. 2a is "a second file portion." These two directory tables, however, are not 
separate portions of a file. Specifically, Evans discloses: 

[0038] In configuring the intranet, each of the application layer packet 
forwarding computers (CI, C2, C3) is manually configured with a site area 
multicast directory (e.g. FIG. 2a in respect of CI). The directory lists possible sets 
of recipients (left-hand column) and corresponding IEEE 802 addresses (right- 
hand column). . . . 

[0041] The next stage in the configuration procedure is to create a set-to- 
IP address conversion table to be stored on the organisation level packet 
forwarding computer P. This table is similar to that (e.g. FIG. 2a) created on each 
of the site-level forwarding computers (CI, C2, C3), but the sets of recipients in 
the table created on forwarding computer P are sets of site-level forwarding 
computers (CI, C2, C3) rather than sets of news application servers (HI to H9). . . 
. One possible example of the contents of the set-to-IP address conversion table 
stored in the organisation-level forwarding computer P is shown in FIG. 2b. 
(Evans, page 3, paras. 0038 and 0041.) 

Evans never suggests that the "site area multicast directory" and the "set-to-IP address 
conversion table" are separate portions of a common file. Instead, Evans suggests that these data 
structures are created at different stages in the process of configuring an intranet. Evans does not 
disclose storing separate portions of a common file because Evans is not even a file storage 
system, much less an intelligent distributed file storage system. 

Simply put, Evans is about multicast data distribution over a network, not a distributed, 
file-based storage system. It is not clear whether the Examiner believes that Evans is a 
distributed file storage system or believes that a person of ordinary skill would be able to change 
Evans into a distributed file storage system. In the Office Action, the Examiner concluded: 
"[H]ence, with the teachings of Evans and Massa in front of him/her, it would have been obvious 
for an ordinary skilled person in the art at the time of the invention was made, to apply the well 
known data distribution techniques as taught by Massa in Evan's system, for the purpose to 
distribute data across storage modules, such that, the combined system is upgraded as a robust 
storage system that includes the capability to recover data from the working disk drives if one 
disk fails in the system in a combination as suggested by Massa [e.g., Massa: col. 1, lines 14- 
24]." As described above, Evans is not a distributed file storage system; hence, it is not possible 
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to "apply" Massa to "Evan's system" in order "to distribute data across storage modules." The 
network-traffic reducing method that Evans discloses cannot be combined with Massa or any 
other cited reference to construct a distributed file storage system. Thus, there is no reason to 
combine the references as the Examiner suggests. Furthermore, the combination of the 
references would not disclose all of the elements of the claimed invention, as already described 
above. 

Finally, the Examiner did not expressly recite where Evans or Massa disclose the 
elements of Claims 62 and 67, which claim, respectively, "[a] file based distributed storage 
system" comprising, in part, "several storage modules linked together, each of which is 
configured to handle read and write requests on behalf of the entire distributed storage system." 
As discussed above, Evans "relates to a method of operating a transmitter to distribute data 
elements to one or more receivers over a network." Thus, the components disclosed in Evans are 
not storage modules configured to handle read and write requests on behalf of an entire 
distributed storage system. 

Because claims 1, 62, and 67 are not disclosed by the combination of Evans and Massa, 
the corresponding dependant claims — Claims 2-12, 43, 63-66, and 68-70— are similarly not 
disclosed. 

F. Discussion of Rejection of Claims 4-6 Under Section 103(a) 

The Examiner rejected Claims 4-6 under 35 U.S.C. 103(a) as being unpatentable over the 
combination of Evans, Massa, and Beardsley et al. (U.S. Patent No. 6,502,174). As described 
above, the combination of Evans and Massa does not disclose the claimed subject matter of 
Claim 1 . The Examiner does not allege that the combination of Evans, Massa, and Beardsley 
discloses the claimed subject matter of Claim 1. Because Claims 4-6 are dependent upon Claim 
1 , the combination of Evans, Massa, and Beardsley also does not disclose Claims 4-6 and, 
therefore, are not obvious in view of the combination. 

G. Discussion of Rejection of Claims 62 and 67 Under Section 102(b) 

The Examiner rejected Claims 62 and 67 under Section 102(b) as being anticipated by 
Mason, Jr. (U.S. Patent No. 5,884,098). Applicants respectfully disagree with the Examiner's 
rejection. Mason "relates to the caching of data and meta-data in controllers implementing the 
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RAID Level 5 architecture." Mason , col. 1, lines 13-14. Mason does not disclose the file based 
distributed storage systems claimed by Claims 62 and 67. 

With respect to both Claims 62 and 67, Mason does not disclose "several storage modules 
linked together, each of which is configured to handle read and write requests on behalf of the 
entire distributed storage system." The Examiner alleges that "Fig(s). 1 & 3 and associated 
texts," which are labeled as 'Trior Art," disclose this claim element. Figures 1 and 3 (and 
Mason, in general), however, disclose only a single "RAID-based disk controller." For example, 
Mason discloses: 

A typical RAID-based disk controller 101 is shown in FIG.l The 
controller is connected to a host computer (not shown), through a host port 103. 
Input/output (I/O) transactions are received through the host port by a host I/O 
processor 105. The host I/O processor is responsible for receiving commands 
from the host computer to the RAID array and for transferring data and command 
status responses from the RAID array back to the host computer. Commands 
from the host computer are typically requests to perform an operation on a number 
of blocks, i.e., a logical block count (LBC), beginning with a specified logical 
block address (LBA) within the RAID array. (Mason, col. 1, lines 66-67, col. 2, 
lines 1-10.) 

A "typical RAID-based disk controller" is not "several storage modules linked together." Mason 
does disclose a "a plurality of physical disk drives" in communication with the RAID disk 
controller, but the individual physical disk drives are not "configured to handle read and write 
requests on behalf of the entire distributed storage system," even assuming for the sake of 
argument that Mason discloses a distributed storage system. Each of the physical disk drives, 
disclosed in Mason, is controlled by the same disk controller, and only this disk controller 
handles read and write requests on behalf of the entire storage system. For example, Mason 



The RAID disk controller also has a disk array interface port 107 which 
communicates with a plurality of physical disk drives 109. Data I/Os and other 
commands to be executed by the physical disk drives of the RAID array are 
processed by a disk array I/O processor 1 1 1 executing RAID Level 5 algorithms. 
The host commands relating to logical locations (LBA, LBC) are processed into a 
plurality of physical I/O operations which are in turn processed by a physical disk 
handler 115 into physical I/O commands for specific physical disk drives 109. 
For example, a disk write of several blocks may be organized into stripes and 



discloses: 
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divided into individual disk I/O operations, (Mason, col. 2, lines 1 1—22, emphasis 
added.) 

Thus, Mason does not disclose "[a] file based distributed storage system comprising: several 
storage modules linked together, each of which is configured to handle read and write requests on 
behalf of the entire distributed storage system . . . 

With respect to Claim 62, Mason also does not disclose "directory metadata configured to 
be used to identify the location of each file stored on the storage system." The Examiner alleges 
that Mason, col. 1, lines 36-65 disclose this claim element. This text, however, discloses only 
the use of parity information for purposes of error correction. Specifically, Mason discloses: 

As described therein, disk data are divided into stripes. See also FIG. 3, 
which illustrates a RAID Level 5 disk set including four disks, DISK1 -DISK4, 
and a stripe width of five blocks. Stripes 301, 302, and 303 contain data of two 
kinds, host data D and meta-data P. Host data D, which is the information stored, 
retrieved and manipulated by the host computer, is for convenience referred to 
hereinafter simply as data D. Meta-data P is used exclusively by the disk array 
controller and perhaps other disk subsystem components for the control and 
maintenance of the disk array system. For example, one type of meta-data P may 
be parity information. Stripes are recorded as sequential blocks on a plurality of 
different disk drives. Each stripe includes a plurality of data blocks D and one 
additional set of blocks called parity blocks P. The parity blocks P contain the 
logical exclusive-OR (XOR) of the plurality of data blocks D, and is recorded on 
an additional disk drive. Conventionally, the parity blocks P are distributed among 
all the disk drives of an array, as shown in FIG. 3, in order to avoid drive 
contention during write operations. The use of parity blocks P improves 
availability of all of the data in a stripe. When one drive is unavailable, for 
example, the missing data block from a stripe can be reconstructed from the parity 
block and the available data blocks. The contents of the parity block is simply 
XORed with the data blocks remaining. The result of this XOR operation is the 
data from the missing drive. Once such a drive has been repaired, data can be 
restored to the repaired drive using the parity blocks and data blocks from each 
good drive in similar fashion. (Mason, col. 1, lines 36-65.) 

Parity information is not "directory metadata configured to be used to identify the location of 
each file stored on the storage system." 

With respect to Claim 67, Mason also does not disclose "file metadata configured to be 
used to identify the location of data blocks comprising a file stored on the storage system." The 
Examiner does not expressly allege where Mason discloses this claim element, but it appears that 
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the Examiner also relies on Mason, col. 1, lines 36-65. Parity information is also not "file 
metadata configured to be used to identify the location of data blocks comprising a file stored on 
the storage system." 

Because Mason does not disclose, at least, the claim elements discussed above, Mason 
does not anticipate independent Claims 62 and 67. 

H. Discussion of Rejection of Claims 63-66 and 68-70 Under Section 103(a) 

The Examiner rejected Claims 63-66 and 68-70 under 35 U.S.C 103(a) as being 
unpatentable over Mason in view of Evans. As described above, neither Mason nor Evans 
discloses the claimed subject matter of Claims 62 and 67. Furthermore, the combination of these 
references does not disclose the claimed subject matter, as neither reference discloses at least one 
of the above-identified claimed elements. Because the combination of these references does not 
disclose Claims 62 and 67, Claims 63-66 and 68-70, which depend, respectively, thereon, are 
also not disclosed and, therefore, are not obvious in view of the combination. 

I. Evidence of Secondary Considerations Demonstrating Nonobviousness 

As explained above, the combination of cited references is not properly combinable as the 
Examiner suggests, and, even if combined, they do not disclose the claimed subject matter. 
Accordingly, the claimed subject matter is not obvious in view of the cited references or any 
combination thereof. In further support of this conclusion, Applicants submit the signed 
declaration of Sujal Patel, an inventor of the present application and the Chief Technology 
Officer of Isilon Systems, Inc, assignee of the present application, discussing evidence of 
secondary considerations supporting the conclusion that the claimed subject matter is not 
obvious. 
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CONCLUSION 



In view of the foregoing comments, it is respectfully submitted that the present 
application is fully in condition for allowance, and such action is earnestly solicited. If any 
questions remain, however, the Examiner is cordially invited to contact the undersigned attorney 
so that any such matters may be promptly resolved. 

Please charge any additional fees, including any fees for additional extension of time, or 
credit overpayment to Deposit Account No. 11-1410. 



Respectfully submitted, 



KNOBBE, MARTENS, OLSON & BEAR, LLP 




Arthur S. Rose 
Registration No. 28,038 
Attorney of Record 
Customer No. 20,995 
(949) 760-0404 
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